Parallel Garbage Collection with Larceny and Cilk

Automated memory management is becoming a standard feature for programming language runtimes. Requiring developers to explicitly release blocks of memory that they believe to be no longer in use often leads to space leaks and bugs. Also, requiring the developers to explicitly release memory leads to significant complication when interfacing different program modules. Therefore, many modern programming languages such as Java and C# require that the runtime remove this burden from the shoulders of the human developer, and instead the runtime selects objects that could never be used, and reclaims them itself. However, most garbage collectors are written assuming that they are hosted on a single sequential processor, rather than on a machine with many processing units available. As machines offer more and more processing units, it will be important for the garbage collectors to make use of all of the processing units available to ensure that programs using automatic memory management remain competitive with programs using explicit memory management. Parallel garbage collectors have been the subject of previous research [6, 1, 4]. I decided to evaluate how hard it would be to take an existing state-of-the-art research garbage collector and parallelize it. Since some successful parallel garbage collectors promoted work stealing [2] as an effective load-balancing technique, I decided it would also be useful to use Cilk as the underlying parallel runtime. Unfortunately, this decision proved premature. While I managed to work through most of the issues I encountered with Cilk, I am still stymied by a particularly nasty problem which I am actively investigating with the current Cilk maintainers (see subsection 5.3).